It's true that Linus is simply the head of the maintenance tree, but the fact that he isn't the driver of new features seems to support my thesis that he doesn't have much need to look ahead very far. That function is generally handled by others lower in the tree, or completely outside of it.

I'm not sure I see my logic failure. Could you elaborate? Am I emulating Eliza? :)

You're getting grumpy, old man. :-)

Nothing a good card sorter couldn't fix. That's why we use line numbers on our COBOL decks and all that. :)

Er. UseD. UseD. :)

Meh. Real-time public safety software should not be running in an environment which allows an application to arbitrarily request memory.

I've written code for multiple mainframe online transaction environments and in UNIX C/C++ and Java environments. Guess which one is more problematic when it comes to memory leaks and other similar issues?

I'm hardly suggesting that a mainframe environment is a viable answer, but the approach that such environments take was taken for a reason. Controlled environments are far less prone to programmer stupidity than uncontrolled ones.

One advantage of many airline online transaction systems: An applications programmer cannot do a malloc equivalent.

Programs are created with a fixed memory size, and complex applications are simply a series of program modules which pass data between each other via common memory areas or memory-mapped files.

Memory leaks in such an environment are quite rare.

Linux isn't a corporation. Also, for something as specific as an OS kernel, I'm not sure there's much to be said for looking out in a detailed manner more than a few major iterations in advance. Sure, there are probably features being considered all the time, but that doesn't make them a focus.

Heh. I'll reply to this non-anonymously. :-)

SLS was fun to play with, but sadly that's all I did. I grabbed a boot and root diskette image plus the A and B series diskettes from a local BBS in the Twin Cities sometime in 1993. SPS 099pl13 or something. Moobasi BBS? Anyway, I also grabbed the X series for XFree86, but I couldn't get it to work (I might've had a Diamond Stealth VRAM at the time which didn't play nice outside of Windows), so I mostly just putzed on the command line.

By the time I tried Slackware for my 486, I'd upgraded to a CL5343-based Speedstar 64 because it worked with OS/2, and XFree86 was perfectly happy.

From there, I want to RH4.2 I think. Red Hat was not to bad with fvwm. It was fun to tinker with the various window managers. olwm, mwm, etc. I didn't really use Linux "seriously" until much latter. I was happy with my OS/2 2.1 GA+SP setup, and with Warp 3, so Linux was more a curiosity than a necessity for me.

The white house cannot lie. It's a house. :-) But the residents thereof might.

You must be new. Cerfification does not imply functional. :(

It would be easier to teach new programmers the old mainframe environment we used to use than the new Java environment that replaced it. Not that Java is inherently difficult in itself. It's just that the newer system had to reinvent so many wheels that were performed "under the hood" on the mainframe that the application itself became a lot more complex. On the older system, applications programmers could concentrate on the application and not networking, file logging, security, etc.

One of the reasons cited for moving off the old environment was a lack of people with mainframe skills. Mainframe isn't a skill ... it's just an OS, editor, set of languages, and programmer environment like anything else, and simpler than many.

Thankfully, not all companies are that shortsighted. :) I'm past your limit by 20 years now, and yet I'm still elbows deep in code and relatively young compared to many of my cow orkers, though as of last year it's more shell, PHP, Perl, and C++ bits than the Fortran 77 I was writing back when I started my career.

My most recent partner in crime (manager, teammate, etc.) just retired in January of this year. He had 20 years of seniority on me, literally, and he was still very very good at what he did.

Don't underestimate the combination of a good mind, good training, and a few solid decades of hard-earned OJT. Sometimes younger programmers are better, and that's good, but having an old fart or three around to mentor (and help by spotting and correcting blatant mistakes) is one of the fastest ways to learn. I had several mentors coming out of college, and i'm thankful for all of them.

Many developers share that view. Many others do not. Is this really the time and place?

"Go" at a stop light or stop sign means "go with caution" anyway, so the behavior of others doesn't matter as long as you drive defensively.

I think most posters here are too young to know what you're talking about. :-)

VirtuaWin is neither buggy nor slow. I've used it for years on XP boxes, and even though I prefer some Linux virtual desktop implementation, this one is at least as good than most of those.